Karl Gardner, Following-up on this:
Based on my understanding of your scenario description:
-- If another user who visited this same site at a later time would be able to access that same key-value pair in memory?
Yes, they would.
-- does this key-value pair persist in memory after the https session has finished?
Yes, it does.
--If the keys are global. This essentially means it persists in memory (for any user) after the key-value pair is set?
That is correct.
There are limits that might lead to cache entries being evicted, but these limits have no connection to the user or the HTTPS session.
Just to highlight, depending on your requirement - you may consider to use MemoryCache directly with AddMemoryCache instead of AddDistributedMemoryCache. Unless you need a component that requires IDistributedCache or plan to switch to a different cache store, this approach offers more flexibility, such as the ability to store arbitrary objects rather than just byte arrays and set priority levels for each cache entry.
Also, probably worth pointing to sessionstate which is per-session (not to be confused with per-user) and built on top of IDistributedCache (which means you can use AddDistributedMemoryCache to back it).
Please checkout the note in the doc: Warning
Don't store sensitive data in session state. The user might not close the browser and clear the session cookie. Some browsers maintain valid session cookies across browser windows. A session might not be restricted to a single user. The next user might continue to browse the app with the same session cookie.
If the answer helped (pointed you in the right direction) > please click Accept Answer Or please share the requested/more info to help you better.